REMARKS 



35 use 112. first paragraph rejections 



Claims 22, 26 and 28 were rejected under 35 USC 1 12, first paragraph based on the 
terminology "upper level utilization". Applicant respectfiilly traverses this rejection as applied 
to amended claims 22, 26 and 28 and new claim 36, based on the following. The specification 
states, "Referring to Figure 5, the analyzer module 230 of the management server 140 receives 
the server statistics in the XML data streams 220 and at step 500 the analyzer module 230 
analyzes the server statistics to determine whether the server 145 to 155 has reached a 
predetermined threshold". Page 8 lines 28-31. "Referring to Figure 6 at step 600, the resource 
allocation module 235 determines whether a new server should be added to a current pool of 
allocated servers 145-155 if the performance threshold has been exceeded or if a server should 
be removed from the current pool of allocated servers and returned to the free resource pool." 
Page 8 lines 38-41. "The present invention advantageously allows for the optimisation of a 
server's performance such that a server can be allocated or deallocated from a server pool 
depending on the server's performance for example if a server is stretched to capacity or equally 
if a server is under utilised." Page 2 line 41 to Page 3 line 2. Thus, the specification sufficient 
explains that if the server has reached an upper threshold of utilization (relating to capacity), 
then another server should be allocated to the server pool or cluster. 



35 USC 1 12. second paragraph rejections 



Claim 22 was found objectionable under 35 USC 1 12, second paragraph allegedly 
because "There is insufficient antecedent basis for this limitation ["another"] in the claim." 
"Another" is a contraction for "an other", and therefore is an introduction of a element and does 

require antecedent basis. 
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Claims 22, 26 and 28 were rejected under 35 USC 1 12, second paragraph allegedly 
because "It is unclear what the applicant means by upper level utilization". This is explained 
above relative to claims 22, 26, 28 and 36. 

Claims 24, 27, 32 and 33 were rejected under 35 USC 1 12, second paragarph allegedly 
because "It is unclear what the applicant means by under utilized". The specification states, 
"Referring to Figure 6 at step 600, the resource allocation module 235 determines whether a new 
server should be added to a current pool of allocated servers 145-155 if the performance 
threshold has been exceeded or if a server should be removed from the current pool of allocated 
servers and returned to the free resource pool." Page 8 lines 38-41. "The present invention 
advantageously allows for the optimisation of a servers performance such that a server can be 
allocated or deallocated from a server pool depending on the server's performance for example if 
a server is sfretched to capacity or equally if a server is under utilised." Page 2 line 41 to Page 3 
line 2. Thus, the specification sufficient explains that if the server is under utilised, then it can 
be de-allocated from the server pool or cluster. This clarification has been added to claims 24, 
27, 32, 33 and 37. 

Claims 29, 30 and 35 were foirnd objectionable under 35 USC 1 12, second paragraph 
allegedly because "It is unclear how request is being handled". The terminology "handling a 
request" is a well known term in the art. A request can be handled in a variety of manners 
depending on the nature of the request. For example, if the request is a valid request for a web 
page, then furnishing the web page in response to this request is an example of handling the 
request. An example of handling a request is described on Page 7 lines 26-37. Therefore, even 
though the terminology "handling the request" is broad, it is not vague. 
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Claims 24, 25, 28, 30, 31 and 33 were found objectionable under 35 USC 1 12, second 
paragraph allegedly because "It is unclear what the applicant means by automatically." The term 
"automatically" means that a step is performed by a program or apparatus without human 
decision to perform that step. For example, if a computer program proceeds from one step to the 
next step without human intervention between the one step and this next step, that is an example 
of automatic performance of this next step. 

Claim 33 was found objectionable under 35 USC 1 12, second paragraph allegedly 
because "It is unclear what the applicant means by subsequently". The term "subsequently" 
means after prior steps are performed. 

35 USC 102 rejection 

Claims 22-33 and 35 were rejected under 35 USC 102 based on US Patent 6,801,949 to 
Bruck et al. Applicant respectfiiUy traverses this rejection based on the foUowdng. 

Claim 22 recites a method for allocating servers to a cluster of servers. Performance data 
of a first server is automatically sent to a second server. The first server is part of the cluster of 
servers. Based on the performance data, the second server determines if the first server has 
reached a predetermined upper level of utilization. If the first server has reached the 
predetermined upper level of utilization, the second server automatically sends a reconfiguration 
request to a server responsible for allocating servers to the cluster to allocate another server to 
the cluster. In response, the responsible server automatically identifies another, available server 
and connection information for the other server and automatically allocates the other server to 
the cluster. 



10/526,810 



11 



GB920020049US1 



Bruck et al. disclose: 

"A distributed server cluster for computer network data traffic dynamically reconfigures 
traffic assignments among multiple server machines for increased network availability. If 
one of the servers becomes unavailable, traffic assignments are moved among the multiple 
servers such that network availability is substantially unchanged. The fi-ont-layer servers of 
the server cluster communicate with each other such that automatic, dynamic traffic 
assignment reconfiguration occurs in response to machines being added and deleted from the 
cluster, with no loss in functionality for the cluster overall, in a process that is transparent to 
network users, thereby providing a distributed server system functionality that is scalable. 
Thus, operation of the distributed server cluster remains consistent as machines are added 
and deleted from the cluster. Each machine of the distributed cluster can continue with any 
applications that may be running, such as for implemented its server functioning, while 
participating in the distributed server cluster and dynamic reconfiguration processing of the 
present invention. In this way, the invention substantially maintains network availability 
regardless of machine failures, so that there is a single point of failure and no lapse in server 
cluster functionality." (Emphasis added) Bruck et al. Column 3 lines 19-40. 

"The operation of the servers on both layers is monitored, and when a server failure at either 
layer is detected, the system automatically shifts network traffic from the failed machine to 
one or more operational machines, reconfiguring front layer servers as needed without 
interrupting operation of the server system. The server system automatically accommodates 
additional machines in the server cluster, without service interruption." (Emphasis added) 
Column 2 lines 47-54. 

Thus, Bruck et al. are concemed with responding to machine failures by re-routing network 
fraffic to the operational machines in the cluster. Bruck et al. also disclose: 

"If the starting computer is actually attempting to recover or regenerate a token, and is not 
involved in an initial start sequence, then it could use the UDP message to send a "9 11 "or 
notification message, as described above. When the computer rejoins the cluster, it will use 
10/526,810 12 GB920020049US1 



the current cluster setup information in a token message for the cluster properties. ... If the 
starting computer receives a reply to the UDP message, then it knows other machines are 
active in the cluster, and it will attempt to join the cluster." Column 14 line 65 to Column 15 
line 2 and Column 15 lines 40-42. 

Thus, Bruck et al. return a server to its cluster when the server returns to operability. In contrast 
to independent claim 22, Bruck et al do not automatically add another server to a cluster in 
response to a predetermined upper level of utilization being reached for a server in the cluster. 
Therefore, the rejection under 35 USC 102 should be withdrawn. Moreover, there is no 
suggestion in Bruck et al. to automatically add another server to a cluster in response to a 
predetermined upper level of utilization being reached for a server in the cluster. Bruck et al. 
merely return a server to its cluster when it returns to operability. Therefore, no rejection under 
35 USC 103 should be made. 

Claims 23-25 depend on claim 22, and therefore, distinguish over the prior art for the 

same reasons as does claim 22. 

Dependent claim 24 also recites that based on the performance data, the second server 
determines if the first server is fiinctional but under utilized such that the second server is no 
longer needed in the cluster. If the first server is fiinctional but under utilized and no longer 
needed in the cluster, the second server automatically sends a reconfiguration request to the 
server responsible for allocating servers to the cluster to de-allocate the first server fi-om the 
cluster. In response, the responsible server automatically de-allocates the first server fi"om the 
cluster. 
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As explained above, Bruck et al. remove a server from a cluster when the server fails. 
Bruck et al. do not remove a functional server from a cluster based on performance data where 
the server is under utilized such that the server is no longer needed in the cluster. Therefore, the 
rejection under 35 USC 102 should be withdrawn. Moreover, there is no suggestion in Bruck et 
al. to automatically remove a functional server from a cluster in response to performance data 
where the server is under utilized such that the server is no longer needed in the cluster. Bruck 
et al. merely remove a server from a cluster when the server fails. Therefore, no rejection under 
35 USC 103 should be made. 

Independent claim 26 distingishes over the prior art for the same reasons as does claim 

22. 

Claim 27 depends on claim 26, and therefore, distinguishes over the prior art for the same 
reasons as does claim 36. Dependent claim 27 further distinguishes over the prior art for the 
same reasons that dependent claim 24 fiirther distinguishes over the prior art. 

Independent claim 28 distingishes over the prior art for the same reasons as does claim 

22. 

Claims 29-35 depend on claim 28, and therefore, distinguish over the prior art for the 
same reasons as does claim 28. 

Dependent claim 32 further distinguishes over the prior art for the same reasons that 
dependent claim 24 further distinguishes over the prior art. 

US 2002/0032768 to Voskuil pertains to automatic configuration of an application which 
is installed, and therefore, does not fill the foregoing gaps in Bruck et al. 

Independent claim 36 distingishes over the prior art for the same reasons as does claim 

22. 
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Claim 37 depends on claim 36, and therefore, distinguish over the prior art for the same 
reasons as does claim 36. 

Dependent claim 37 further distinguishes over the prior art for the same reasons that 
dependent claim 24 further distinguishes over the prior art. 

Based on the foregoing, the present patent application as amended above should be 
allowed. 



Respectfully submitted, 



Dated: 11/06/2007 
Telephone: 607-429-4368 
Fax No.: 607-429-4119 



/Arthur J. Samodovitz/ 
Arthur J. Samodovitz 
Reg. No. 3 1,297 
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